Documentation build overview

📚 cpython-previews | 🛠️ Build #32457899 | 📁 Comparing 2384f46 against main (76b3923)

  🔍 Preview build  

I concur with @ZeroIntensity who wrote that threading is a bad place for this. I'm not sure that threading is a good home for the 3 added functions (serialize, synchronized, concurrent_tee). IMO itertools would be a better home for them.

For example, I would expect @threading.synchronized (which sounds like synchronized in Java) to work on any function, such as:

import threading

class Demo:
    _next_id = 0

    @threading.synchronized
    def get_id(self):
        self._next_id += 1
        return self._next_id

But calling get_id() fails with:

Traceback (most recent call last):
  File "/home/vstinner/python/main/x.py", line 12, in <module>
    print(demo.get_id())
          ~~~~~~~~~~~^^
  File "/home/vstinner/python/main/Lib/threading.py", line 930, in inner
    return serialize(iterator)
  File "/home/vstinner/python/main/Lib/threading.py", line 869, in __init__
    self._iterator = iter(iterable)
                     ~~~~^^^^^^^^^^
TypeError: 'int' object is not iterable

concurrent_tee() sounds very specific, whereas currently threading only contains very generic tooling to write multithreaded code. itertools contains many functions, so should we expect to pop up more itertools functions in threading? As an user, it's uneasy for me to choose between threading.concurrent_tee() and itertools.tee() who are in two different modules. I would expect them to be in the same module, and I expect itertools.tee() to mention concurrent_tee() and explain when it should be used instead.